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REMARKS 

In an Office Action marked "Fmaf dated February 25, 2008, claims 1-28 were 
pending in the application. Claims 1-5, 8-12, 15-19, and 22-26 were rejected under 35 
U.S.C. § 103(a) as being unpatentable over Yoneda et al. (U.S. App. No. 2007/0076703) 
in view of Bou-Diab et al. (U.S. App. No. 2006/0187950). Claims 6, 7, 13, 14, 20, 21, 27, 
and 28 were rejected under 35 U.S.C. § 103(a) as being unpatentable over Yoneda and 
Bou-Diab as applied to claims 1, 8, 15, 22, and 23, and further in view of Gainer, et al. 
(U.S. App. No. 2007/0121628). 

Claims 1-5, 8-12, 15-19, and 22-26 were rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Yoneda in view of Bou-Diab. Applicants respectfully traverse 
this rejection. 

Independent claim 1 is a method that requires: 

receiving by a layer 2 switch coupled between a group of receivers and a router, 

requests for traffic from said group of receivers; 
determining, by said switch, whether said traffic requests contain incompatible 

request types; 

if incompatible request types exist, then separating said traffic requests into at 

least two groups based on type; and 
sending requests of different types to said router from distinct addresses. 
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There is no mention in either cited reference for determining whether there are 
incompatible request types. The cite to Yoneda to show that it handles both SSM and 
ASM types is irrelevant, since there is no mention or suggestion there that these would be 
incompatible. It is only with the hindsight of the present invention that they might be seen 
as such. But notably, they are not distinguished because they are identified as 
incompatible. Thus, because this is not an issue in the cited references, "determining, by 
said switch, whether said traffic requests contain incompatible request types" is a 
missing claimed element in the combined reference. It should also be noted that neither 
reference shows or suggests providing distinct addresses based on incompatible request 
types, and, in particular, SSM v. ASM type requests. 

The Layer 2 switch shown in Bou-Diab is significantly different from the one 
shown in the present invention. Bou-Diab shows using VPLS technology for providing 
OSI layer 2 encapsulated packets between geographically disparate LANs which are 
members of the same VPLS context (J 49). This is very different from the present 
invention where: 

When a receiver 140 desires to receive content from the source 105, it will 
send IGMP messages towards router 120 to indicate the content it is interested in 
group address. The router 120 and other routers within the network cloud 110 will 
use IP multicast routing protocols to acquire the content, and send it into LAN 150. 
The content will be available to all systems connected to the LAN; thus, those 
receivers who do not desire the content will simply ignore the content. 
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Figure 2 contains the structure of FIG. 1 and further includes an L2 switch 

130 provided to more efficiently manage bandwidth on the access network 150. To 

prevent content from clogging the ports of receivers, networks typically include the 

L2 switch 130, also known as a LAN switch, which is a device configured to direct 

traffic only towards interested ports. This directing may be accomplished through 

IGMP "snooping", where L2 switch passively listens to IGMP messages and learns 

about the traffic demands on the host(s). L2 switches are typically designed to be a 

plug-and-play product that requires little or no user configuration. 

For example, one issue is scalability. In modern systems, as many as 400 
receivers may be connected to a L2 switch, with several L2 switches coupled to a 
single router. Proxy reporting is used to off load some of the work of the router. In 
proxy reporting, the L2 switch aggregates content requests from its attached 
receivers, and presents only one request to the router, making the L2 switch appear 
as another host receiver to the router. 

Thus, the L2 switch as defined by the specification is a typical L2 switch which is 
interposed between a (typically Ethernet) router and a receiver. It interfaces at Layer 2 
between the router and receiver, and is typically essentially transparent to both. In a 
typical example, it routes Ethernet traffic based on Layer 2 MAC addresses. It is similar 
to an L2 hub, except the later rebroadcasts everything to all nodes connected to the hub, 
whereas the switch only transmits packets to the interested nodes. This is significantly 
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different from the L2 tunnels utilized in the Bou-Diab reference, which is one end of an 
L2 bridge between networks and clearly is not "a layer 2 switch coupled between a group 
of receivers and a router". Bou-Diab utilizes Layer 2 tunnels, OSI Layer-2 multicast 
tunnel connectivity, and "OSI Layer-2 Ethernet switching techniques for forwarding OSI 
Layer-2 Ethernet encapsulated packets between geographically disparate LANs which 
are members of the same VPLS context, and Multiprotocol Label Switching (MPLS) for 
Ethernet packet transport between the Ethernet switching nodes across a 
communications network" ([0049]). But while Bou-Diab utilizes L2 Ethernet switching 
techniques, that reference does not disclose, suggest, or teach an actual L2 switch. 

There is further no indication in either cited reference that they "send requests of 
different types to said router from distinct addresses". Rather, they teach away from this, 
having no real ability to segregate by type, but rather Bou-Diab segregates each request, 
regardless of compatibility and types. 

Additionally, the two references are in not analogous art. They are in different 
U.S. subclasses. Further, there is no reason to believe that adding Bou-Diab to Yoneda 
would work. The examiner has the burden of providing a prima facie case of 
obviousness, and one of the requirements of a combined reference is enablement. Thus, 
the examiner bears the burden of at least suggesting how the two references could be 
effectively and operably combined in order to overcome this burden and make his prima 
facie case. 

The examiner's motivation for combining, in order to lower processing 
requirements ignores that the two references are incompatible. Yoneda would be 
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significantly slowed with the addition of the Bou-Diab OSI Layer-2 multicast tunnel 
connectivity, since this is unneeded and wasteful processing in the Yoneda environment. 
Thus, Yoneda teaches away from being combined with Bou-Diab. Additionally, the 
suggestion that a combination would lower processing requirements is a generic 
justification that could be (and is here in two places) used to justify almost any 
conceivable combination. Since it is generic, the examiner bears the burden of showing 
why the combination would lower processing requirements in order to provide a prima 
facie case of obviousness. This burden has not been met. 

The two technologies are significantly different. The only thing bringing the two 
references together is the hindsight of the present invention. Nevertheless, the examiner 
has not shown any reason whatsoever why a person reasonably skilled in the art would 
ever think of combining these references. Citing lower processing requirements, without 
showing how that would be achieved, does not meet this burden of proof. 

Significant elements are missing from both the cited references. The justification 
cited for combining the two is unavailing. Yoneda teaches away from the combination. 
The combination is unlikely to work. The other independent claims have similar 
limitations. For these reasons, applicants respectfully submit that a prima facie case of 
obviousness has been rebutted for the independent claims, that this rejection is improper, 
request that that limitation be withdrawn, and that these claims be allowed. 

The remaining claims in this section are dependent upon these independent claims, 
and for those reasons, should also be allowable. Further, as to the dependent claims 
rejected in this section, no justification was given except for the justification for rejecting 
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the independent claims. It must be assumed from that that the elements claimed in these 
claims are not present in the two cited reference. For all these reasons, applicants 
respectfully assert that a prima facie case of obviousness has not be made for these 
claims, that their rejection cannot be supported, and request that this rejection be 
withdrawn. 

Claims 6, 7, 13, 14, 20, 21, 27, and 28 were rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Yoneda and Bou-Diab as applied to claims 1, 8, 15, 22, and 23, 
and further in view of Gainer. Applicants respectfully traverse this rejection. 

These claims are dependent upon the independent claims discussed above, and 
should therefore be allowable for the same reasons. Further, the justification given for 
combining references in unavailing. There is no teaching, suggestion, or disclosure that 
combining the third reference would result in a lower implementation cost. The only 
justification for combining them this way is forbidden hindsight. The rejection required 
the use of MAC addresses, and a random disclosure utilizing MAC addresses was 
selected to provide this element. Additionally, it should be noted that essentially all of 
Gainer is cited for these elements without specifically pointing out, as required by the 
MPEP, where the teaching or suggestion resides in the reference. 

For all of these reasons, applicants respectfully submit that a prima facie case of 
obviousness has not been made, that the rejection of these claims is in error, and request 
that this rejection be withdrawn. 
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Applicants respectfully requests that this Amendment be entered. All claims 
should be allowable. Applicants further respectfully requests that a timely Notice of 
Allowance be issued in this case. 

If the Examiner has any questions regarding this application or this response, the 
Examiner is requested to telephone the undersigned at 775-586-9500. 



Respectfully submitted, 

SIERRA PATENT GROUP, LTD. 



Dated: April 15, 2008 /brace e. hayden/ 

Brace E. Hayden 
Reg. No.: 35,539 

Sierra Patent Group, Ltd. 
1663 Hwy 395, Suite 201 
Minden, NV 89423 
(775) 586-9500 



14 



